Deepgram/Models/Analyze/v1/TextSource.cs (1)

7-8: LGTM: Well-structured class declaration with a minor suggestion.

The TextSource class is correctly declared as public, making it accessible for SDK users. The use of a primary constructor is a concise and modern approach.

Consider adding a null check in the constructor to ensure that the text parameter is not null. This can be done using the null-coalescing operator:

public class TextSource(string text)
{
    public string? Text { get; set; } = text ?? throw new ArgumentNullException(nameof(text));
    // ... rest of the class
}

This change would prevent the creation of a TextSource object with a null text value, which might lead to unexpected behavior later.

Deepgram/Clients/Interfaces/v1/IAnalyzeClient.cs (1)

21-27: Enhance XML documentation for better clarity.

The XML documentation for the AnalyzeText method is good, but it could be improved to provide more details about the parameters and return value. Consider adding descriptions for all parameters and the return value.

Here's a suggested improvement for the XML documentation:

/// <summary>
/// Analyzes provided text synchronously.
/// </summary>
/// <param name="source">Text that is to be analyzed.</param>
/// <param name="analyzeSchema">Options for the analysis. Can be null.</param>
/// <param name="cancellationToken">Token to cancel the operation. Optional.</param>
/// <param name="addons">Additional parameters for the analysis. Optional.</param>
/// <param name="headers">Custom headers to be included in the request. Optional.</param>
/// <returns>A Task representing the asynchronous operation, containing a SyncResponse with the analysis results.</returns>

Deepgram/Clients/Analyze/v1/Client.cs (3)

46-70: LGTM! Consider enhancing the method documentation.

The AnalyzeText method is well-implemented and consistent with the existing pattern in the class. It includes proper logging, callback verification, and uses the PostAsync method as expected.

Consider adding a brief description of the cancellationToken, addons, and headers parameters in the XML documentation to provide more clarity on their usage.

 /// <summary>
 ///  Analyze by providing text 
 /// </summary>
 /// <param name="source">Text that is to be analyzed <see cref="TextSource"></param>
 /// <param name="analyzeSchema">Options for the transcription <see cref="AnalyzeSchema"/></param>
+/// <param name="cancellationToken">Optional cancellation token to cancel the operation</param>
+/// <param name="addons">Optional dictionary of additional parameters</param>
+/// <param name="headers">Optional dictionary of custom headers to include in the request</param>
 /// <returns><see cref="SyncResponse"/></returns>

---

185-214: LGTM! Consider enhancing documentation and error handling.

The AnalyzeTextCallBack method is well-implemented and consistent with the existing pattern in the class for asynchronous operations with callbacks. It includes proper logging, callback verification, and uses the PostAsync method as expected.

1. Enhance the method documentation:

 /// <summary>
 /// Analyze by providing text and a CallBack
 /// </summary>
-/// <param name="source">Text that is to be analyzed <see cref="UrlSource"/></param>
+/// <param name="source">Text that is to be analyzed <see cref="TextSource"/></param>
 /// <param name="callBack">CallBack url</param>    
 /// <param name="analyzeSchema">Options for the transcription<see cref="AnalyzeSchema"></param>
+/// <param name="cancellationToken">Optional cancellation token to cancel the operation</param>
+/// <param name="addons">Optional dictionary of additional parameters</param>
+/// <param name="headers">Optional dictionary of custom headers to include in the request</param>
 /// <returns><see cref="AsyncResponse"/></returns>

2. Consider adding null checks for analyzeSchema:

+        analyzeSchema ??= new AnalyzeSchema();
         VerifyOneCallBackSet(nameof(AnalyzeTextCallBack), callBack, analyzeSchema);
         if (callBack != null)
             analyzeSchema.CallBack = callBack;

This ensures that analyzeSchema is never null when used, preventing potential null reference exceptions.

---

Line range hint 1-250: Overall, excellent implementation with good consistency.

The new methods AnalyzeText and AnalyzeTextCallBack are well-integrated into the existing Client class. They follow the established patterns for synchronous and asynchronous operations, maintaining consistency in logging, error handling, and method structure.

For consistency, consider updating the VerifyOneCallBackSet method to use string interpolation for error messages, similar to other parts of the code:

-            var exStr = "CallBack should be set in either the CallBack parameter or AnalyzeSchema.CallBack not in both.";
+            var exStr = $"CallBack should be set in either the CallBack parameter or AnalyzeSchema.CallBack not in both.";
             Log.Error("VerifyNoCallBack", $"Exceptions: {exStr}");

This minor change would align the error message formatting with the rest of the class.

Deepgram.Tests/UnitTests/ClientTests/AnalyzeClientTests.cs (3)

229-251: Consider explicitly setting CallBack to a non-null value.

The test case is well-structured and verifies the correct exception is thrown. However, to make the test more explicit and robust, consider setting the CallBack property to a non-null value before invoking the method.

You could add the following line before the Act and Assert section:

var analyzeSchema = new AutoFaker<AnalyzeSchema>().Generate();
+ analyzeSchema.CallBack = "http://example.com/callback";

This ensures that the test is explicitly checking the scenario where CallBack is not null.

---

288-316: LGTM! Consider updating the method name for accuracy.

The test case is well-implemented and correctly verifies the behavior of AnalyzeTextCallBack when using a callback property. The setup, mocking, and assertions are appropriate.

There's a minor inconsistency in the method name. Consider updating it to reflect that an AsyncResponse is returned:

- public async Task AnalyzeTextCallBack_Should_Call_PostAsync_Returning_SyncResponse_With_CallBack_Property()
+ public async Task AnalyzeTextCallBack_Should_Call_PostAsync_Returning_AsyncResponse_With_CallBack_Property()

This change would make the method name more accurate and consistent with the actual behavior being tested.

---

343-366: LGTM! Consider updating the expected response type for consistency.

The test case is well-implemented and correctly verifies that AnalyzeTextCallBack throws an ArgumentException when no callback is set. The setup, mocking, and assertions are appropriate.

There's a minor inconsistency in the expected response type. Consider updating it to AsyncResponse for consistency with other tests:

- var expectedResponse = new AutoFaker<SyncResponse>().Generate();
+ var expectedResponse = new AutoFaker<AsyncResponse>().Generate();

- analyzeClient.When(x => x.PostAsync<AnalyzeSchema, SyncResponse>(Arg.Any<string>(), Arg.Any<AnalyzeSchema>())).DoNotCallBase();
- analyzeClient.PostAsync<AnalyzeSchema, SyncResponse>(url, Arg.Any<AnalyzeSchema>()).Returns(expectedResponse);
+ analyzeClient.When(x => x.PostAsync<AnalyzeSchema, AsyncResponse>(Arg.Any<string>(), Arg.Any<AnalyzeSchema>())).DoNotCallBase();
+ analyzeClient.PostAsync<AnalyzeSchema, AsyncResponse>(url, Arg.Any<AnalyzeSchema>()).Returns(expectedResponse);

- await analyzeClient.DidNotReceive().PostAsync<AnalyzeSchema, SyncResponse>(url, Arg.Any<AnalyzeSchema>());
+ await analyzeClient.DidNotReceive().PostAsync<AnalyzeSchema, AsyncResponse>(url, Arg.Any<AnalyzeSchema>());

This change would make the test more consistent with the other AnalyzeTextCallBack tests.

Configuration used: CodeRabbit UI
Review profile: CHILL